ソフトウェアアーキテクチャの基礎輪読会 16章
日付：2023/11/24
章：16
調査者：iNoma.icon
章のまとめ
どんな内容が書かれているか？
要約
オーケストレーション駆動サービス志向アーキテクチャ
アーキテクチャ決定に影響を与えがちな外力と、論理的ではあるが最終的には害をなす組織哲学とがあいまって、このアーキテクチャは無用の長物になってしまった。
今は悪影響のほうが目立つため、使われていないアーキテクチャ
アーキテクチャとは、その時代の文脈に沿って理解されるべきである
ここでいう組織哲学とは、
（過度な）再利用のことだと思いますiNoma.icon
歴史と哲学
1990年代後半
企業が大企業化→中小企業との合併、巨大化
コンピュータのリソースは依然として貴重
→可変のスケーラビリティが求められる
今の時代と異なりオープンソースのOSが信頼されていないため、サーバーごとにライセンス料を払う必要があった
再利用が支配的な哲学となる
大きな制限付きの分散アーキテクチャへ
このアーキテクチャは、アーキテクトがどれだけ技術による分散を推し進められるかの好例でもある
トポロジー
図16-1を参照
分類
ビジネスサービス（BS）
最上位に位置し、エントリーポイントを提供
特定のビジネスドメインを中心としたアトミックな動作
「我々は......の業務をしているのか」という問いに肯定的に答えられる
コードは含まれず、入出力、時にスキーマ情報が含まれる
例
ExecuteTrade
PlaceOrder
エンタープライズサービス
再利用できる、粒度の細かい共有の実装
例
CreateCustomer
CalculateQuote
オーケストレーションエンジンを介して結びつけられる
このサービスの構築は、再利用可能な資産を増やすことに繋がる......
はずだったが、現実世界の変化の速さによって拒まれるのが現状
市場、技術の変化、エンジニアリングプラクティス、等の変動
アプリケーションサービス
再利用を想定していない、書き捨てのサービス
インフラストラクチャサービス
運用と密接に連携したインフラチームの関心事を提供
監視 ロギング、認証、認可など
オーケストレーションエンジン
このアーキテクチャの核
ビジネスサービスの実装を繋ぎ合わせる
単一あるいは数個のRDBを利用
BSごとにDBを用意するわけではない
マイクロサービスアーキテクチャとは異なる点
ビジネスサービスとエンタープライズサービスの関係、マッピング方法、トランザクションの境界を定義
実際には、トランザクションの適切な境界を把握するのは困難であった
メッセージフロー
図16-2を参照
すべてのメッセージは（内部呼び出しであっても）オーケストレーションエンジン（エンタープライズサービスバス）を経由する
再利用
このアーキテクチャの目的は、サービスレベルで再利用できる資源を増やしていくこと
例
図16-3,16-4
各部門が全て「Customer」の概念を含んでいるため、サービスとして切り出した
再利用には成功したが、Customerサービスの変更は事業部全てのサービスに影響
協調的なデプロイ、全体的なテストが求められる→開発効率の低下へ
アーキテクチャ特性の評価
マシ
弾力性、スケーラビリティ
最悪
テスト容易性、デプロイ容易性
コスト、シンプルさ
モノリシックアーキテクチャと分散アーキテクチャの両方のデメリットを持つ
技術的に分散しているが、オーケストレーションエンジンやDBが単一であるため
総評
技術による分割と分散トランザクションの、実用的な限界を示したアーキテクチャ
付録A
1. サービス志向アーキテクチャの主な推進力は何だったか
限られたコンピュータリソースを経済的に利用するための、再利用の哲学
2. サービス志向アーキテクチャにおける4つの主なサービスタイプとは何か
略
3. サービス志向アーキテクチャの没落に繋がった要因をいくつか挙げよ
分散トランザクションにおいて、適切な境界を見つけることの困難さ
ドメイン概念の分散
開発運用の困難さに対するパフォーマンスの低さ
4. サービス志向アーキテクチャは技術によって分割されているか、それともドメインによって分割されているか
技術によって分割されている
4. SOAではドメインの再利用性はどのように対処されているか 運用上の再利用はどのように対処されているか
サービスのさまざまな層に薄く分散
複数の異なるサービスを横断している
応用
code:sample.kt
質疑応答